Technical Field
This disclosure relates generally to a generic approach to extending and enriching the authentication and authorization capabilities of software applications without any change to the applications themselves.
Background of the Related Art
Currently, enterprises deploy a combination of various forms of network/resource access solutions, such as VPN (virtual private network), VDI (virtual desktop infrastructure), SBC (server-based computing), Web Access Gateways (e.g. IBM® Tivoli® WebSEAL® Access Manager), and wireless LAN gateways. Most of these “access” applications require the user to authenticate at a client side of the application (using an application client), after which the authentication data is forwarded to an authentication server (e.g., based on LDAP or RADIUS) for verification. This way, there is need for an individual application to manage user credentials or to maintain its own user database. In this approach, the user just enters a username/password pair to the application client, which then forwards the data to the application server, which in turn forwards it to an authentication server for verification. This approach works well for password and OTP (one-time password) logons where the application client just need a relatively simple user interface (UI) to acquire the password/OTP from the user, while the application server simply forwards the password/OTP along to the authentication server for verification. In addition, and by modifying the application client and server codes accordingly, some VPN and related applications also have support for smartcard (PKI-based) authentication. Such support has been made possible because smartcard PKI has well-established standards and built-in support from many operating systems.
Many new and innovative forms of authentication technologies have emerged over the recent years. Nevertheless, it has become increasingly difficult for application product vendors to keep up with such innovations. In particular, there is no obvious approach and no dominant standards for an application vendor to follow to integrate with arbitrary authentication products. Many of these authentication products/technologies have a “client” component (an authentication agent or “Auth Agent”) and a “server” component (an authentication server or “Auth Server”). The Auth Agent is responsible for interacting with authentication tokens/devices (e.g., fingerprint readers), for interacting with users (e.g., to guide user on how to scan his or her eyes), for gathering additional attributes from the machine (e.g. IP address, geo-location, and the like), and for passing along the collected data to the Auth Server for verification. These technologies also often take advantage of existing mechanisms in the RADIUS protocol (called “EAP”) for the application server to pass along to the Auth Server authentication data collected from the client side; that said, there is no standard mechanism for the Auth Agent to pass the information to the application client. In particular, there is no known solution for the Auth Agent and Auth Server to communicate arbitrary information or data through the application client and server. As such, VPNs and similar access applications have not supported new forms of authentication in recent years
It is known to deploy some authentication solutions (e.g., an enterprise single sign-on (SSO) solution) that perform two-factor authentication (e.g., with biometrics) of a user upon logon to his/her machine, but where subsequent logon to applications involves just a single password. This approach leaves the applications still protected by just a single factor. Just as importantly, in these approaches the authentication server typically is still hidden behind a VPN, so even when it is used the Auth Agent has no access to the server until the VPN connection is enabled. This means that the Auth Agent needs to be able to authenticate the user using data that is cached at the client machine. If no data is cached, however, the Auth Agent will not be able to authenticate the user. Moreover, if the data cached is stale, the Auth Agent may let the user through inappropriately. More importantly, performing authentication in such an off-line manner precludes the authentication product from making use of up-to-date and much richer information that may be available at the Auth Server (e.g. whether user has been locked out or revoked, whether this current access is consistent with user's past access patterns, and the like).
A related issue is authorization. Many enterprises are now seeking solutions where authorization policies can be managed centrally, and where authorization decisions can be based on a wide variety of information about the user and the machine/network he or she is using (e.g., is the Windows OS patched, does it have an anti-virus program, or the like). Existing client-server based authentication products/technologies do not address the additional requirements that arise with respect to authorization.